dragonsdogmafandomcom-20200223-history
User talk:Rcfox
Tables Thanks for your additions of the huge tables - much appreciated - good work! ... I've tried to fix the sorting - initial edits on Category:Torso Armor .. Basically the table sorting doesn't work unless only a single row starts with the ! mark .. so I;ve converted text like this : :! Hellfire Armor || 146 || 103 || 8% || 8% || 36% || 36% || Fire +3% Ice +3% Lightning +3% Dark +3% || Sleep +20% Lowered Str +20% Lowered Mag Def +20% || 2.78 || Random enhancement assisting with Health Recovery to this : : |'Hellfire Armor' :| 146 || 103 || 8% || 8% || 36% || 36% || Fire +3% Ice +3% Lightning +3% Dark +3% || Sleep +20% Lowered Str +20% Lowered Mag Def +20% || 2.78 || Random enhancement assisting with Health Recovery and now sorting works (on chrome and IE anyway, probably everywhere) - it's no big deal to do as there's a regex replace I can use :^! \[\[\(^]+\)\]\] || to :|'\1'\n| (just ignore if you don't know/like regex technical stuff) ..takes about 15 secs.. I need to take a good look at the Torso armor page to make sure I haven't messed other stuff up with that edit.. There are a couple extra tweaks that can be done to make the sorted table look tidy - for example padding the top header row to "br/" to make it line up nice, maybe it needs lines between columns. I'll make sure there changes to the Torso Armor page are ok before applying to the others - let me know anywhere (here, talk, my talk) if there are problems.. Also I'm tempted to move the lists to a separate page - like is already done at Swords and Category:Swords, with a big link at the top.. but that's not a priority. Thanks again! XuEn (talk) 15:58, June 3, 2017 (UTC) (Not sure if this is the right spot to put a response. Hopefully, you'll see it!) Thanks! I've actually got a script to generate the tables, so I'll update that there too. I'll be posting it on GitHub once I clean it up a bit. Rcfox (talk) 16:04, June 3, 2017 (UTC) :Got it. There were a couple missing which don't matter in the table or affect the appearance eg diff -- I see they are from the original article. :Everything else seems to work perfectly. Thanks again.XuEn (talk) 16:26, June 3, 2017 (UTC) Just a note Hi - I looked at your links and decided to have a go at using the wiki API to trawl and collate some data to make complete listings for the debilitations and resistances pages - you can see examples of the tables at Fire or Curse etc. I had a problem with long render times on the biggest list (fire) - with post page load parse/render times of up to 40seconds on underpowered but modern hardware (eg quad core atom based PC, original iPad) .. long story short the main problem seemed to be the rescale of the large number of small images to the px size given in the markup .. looks like the browser(?) is rescalling the same image everytimg - well probably - anyway - replacing the images with fixed size links (pre-rescaled to the right size) reduced page times by 1/4 - so good. Since some of your pages are big they were also getting long render times - so I'll replace the images with prescaled 32px images I've uploaded. Just letting you know. My worst page times are around 10secs which is ok. If you've got any tips for improving on that (much appreciated - I'm script monkey) - please let me know. Otherwise nothing to see here. ;tldr I've swapped out some of your icons with pre-scaled pngs for improved performance on shitty hardware, also using the same images on my own additions eg see the table at Fire. Images here: The naming scheme is: Frozen.png becomes Frozen32px.png and also FighterN.jpp becomes FighterN32px.png AssassinN32px.png Blindness32px.png Curse32px.png DARK_BASED32px.png DarkResistance32px.png DDicon_assassin32px.png DDicon_fighter32px.png DDicon_mage32px.png DDicon_magicarcher32px.png DDicon_ranger32px.png DDicon_magicknight32px.png DDicon_sorcerer32px.png DDicon_strider32px.png DDicon_warrior32px.png DefenseLowered32px.png DrenchedWater32px.png FAVARMORUSERBOXICON32px.png FighterN32px.png FIRE_BASED32px.png Fire32px.png FireResistance32px.png Frozen32px.png HOLY_BASED32px.png HolyResistance32px.png ICE_BASED32px.png LIGHTNING_BASED32px.png LightningResistance32px.png MageN32px.png MagicarcherN32px.png MagickDefenseLowered32px.png MagickLowered32px.png MagicknightN32px.png Petrification32px.png Poison32px.png Possession32px.png RangerN32px.png Silence32px.png SkillStifling32px.png Sleep32px.png SorcererN32px.png StrengthLowered32px.png StriderN32px.png Tarred32px.png Torpor32px.png WarriorN32px.png IceResistance32px.png ;Update After all that the change doesn't seem to have made as much (if any improvement) at all - looks like there was something wrong with my tests.. Well back to the drawing board.... XuEn (talk) ---- I think a common approach to this problem is to create one larger image with all of the icons and then specify x,y offsets to each icon when it's used. I looked briefly at the documentation and didn't see a great way of doing that though... MediaWiki doesn't seem to support offsets, but you can add a CSS class. However, it seems Wikia just straight up ignores CSS changes on mobile... Rcfox (talk) 02:37, June 10, 2017 (UTC) ::..I'm still trying to find out exactly what the problem is - something odd seems to be happening - when I "preview" an edit in Desktop mode the table layout is quick (under 5 secs), but when I save the edit, and refresh/reload the page layout times increase by 4-10 times .. ::Looking at the network activity it seems about 95% of the time is spent retrieving thousands of very short data:image/gifs - these all seem to be tiny base64 image datas specifically data:image/gif;base64,R0lGODlhAQABAIABAAAAAP///yH5BAEAAAEALAAAAAABAAEAQAICTAEAOw which google tells me is a 1x1 transparent gif. ::Not clear what the purpose of these are - they're not cookies - might be a mediawiki bug - I need to do some reading see if it makes sense..XuEn (talk) ::::I noticed those data:images too. It seems the data:image url is a placeholder, and the actual image gets swapped in by Javascript. The only reference to I could find is this. Rcfox (talk) 03:21, June 10, 2017 (UTC) :::::Thanks - that looks like it - I noticed the actual images are fetched right at the end of the network activity and only once. :::::The data:url fetches from memory still happen in preview mode - but seem to be much faster (or without pauses in between - not sure) - and without the heavy cpu usage. :::::It's not clear to me why the rendering of the same page in the preview box is so much faster.XuEn (talk) :::::::It looks like the image tags aren't using placeholder urls on the preview. Some of the data urls are other things. There's a little arrow icon in the menus, the pencil icon on edit buttons, etc. Rcfox (talk) 03:44, June 10, 2017 (UTC)